1. Field of Invention
The present invention relates generally to the field of computer communications systems. More specifically, the present invention relates to the field of managing transaction messages between computer systems.
2. Background of the Invention
Modern computer systems generally consist of a number of applications working with one another to provide services for users. The applications pass messages between one another containing information and data needed by the applications to perform various tasks. A single communication between the applications, including any messages, protocol handshaking and the like is commonly referred to as a transaction. There are many kinds of transactions that are performed in modern computing environments. Each type of transaction is generally identified by a transaction code (TC).
One area in which messaging between computer systems is required is where companies having existing computing systems, known as legacy systems, must communicate with third party systems. This situation occurs frequently, for example, in the case of telephone companies that have existing legacy systems that must communicate with third party systems to perform various tasks, including ordering services, requesting maintenance, checking statuses and changing service.
The third party computers communicate with the telephone company's legacy systems through an interface called an application programming interface (“API”). The API provides a common set of routines that third party computers can invoke to gain access to the legacy systems. The API generally executes on a gateway computer. The gateway computer provides communication and security services for the communication between the legacy systems and the third party computers.
After a transaction is complete, whether successfully or unsuccessfully, it is generally assigned a status indicator (SI), which indicates the result of the transaction. A transaction code/status indicator pair is commonly referred to as a TCSI. The TCSI contains a transaction code representative of a particular transaction, and a status indicator indicating the status of the transaction.
An exemplary conventional system for providing communication between a telephone company's legacy systems and third party computers through a gateway is shown in FIG. 1. Specifically, third party computers 1-5 communicate with legacy systems 102 through gateway 104. In this example, third party computers 3-5 communicate through the Internet 106, whereas third party computers 1 and 2 have direct connections to gateway 104. A firewall 109 can be provided by gateway 104 to provide security for the legacy systems.
Third party computers 1-5 query legacy systems 102 for information. Conventionally, the request is made by completing a request window or screen displayed to the requester. This request window is part of an API 103. To perform the query, a third party computer, for example, third party computer 2, issues a data request to legacy systems 102 through gateway 104. Gateway 104 provides security and request formatting functions for the particular transaction. That is, gateway 104 reformats the request into a request that legacy systems 102 understand. Gateway 104 receives the information requested and formats it into a response that the requester (third party computer 2 in this case) understands. In the system shown in FIG. 1, messages between the third party computers 1-5 and gateway 104 conform to the ANSI standard, ANSI T1.246-1999, Telecommunications, Operations, Administration, Maintenance and Provisioning (OAM&P)—Information Model and Services for Interfaces between Operations Systems across Jurisdictional Boundaries to Support Configuration Management, which is incorporated by reference herein in its entirety.
A significant problem with this communication paradigm is keeping all communicating computers in conformance with the T1.246 standard when changes to the standard are requested. This problem occurs because of the magnitude of the updating that is required to effectuate a change to the standard. There are a few hundred messages in the standard. Each message can have up to 80 fields of data. When a change is requested, all of the fields in all of the messages may have to be updated in accordance with the change.
Under the T1.246 standard, transactions are categorized into transaction types. Whether a transaction is inbound or outbound is defined with reference to the legacy systems. Thus, inbound transactions are those transactions from the third party systems and outbound transactions are those transactions to the third party systems. There are five inbound transaction types. There can be many outbound message types that correspond to the five inbound message types.
For example, when a third party computer sends a request, for example, an ordering request, the resulting response can include up to 80 fields. Due to incomplete information, or prior agreement, not all 80 fields need be sent in each response. The aforementioned problem arises when, for example, one of the third parties decides to change the information that its computer receives in a given response (outbound) transaction. Consequently, even simple changes conventionally require a complete revision and re-release of the software executing on gateway 104 even though the data elements are defined in the T1.246 standard. New revisions of code require code modification, rebuilding and testing. This is a time consuming and expensive process that can take more than four months to complete.
Thus, there is a need for a system and method for facilitating these changes without requiring modification to the software executing on the gateway and its consequent rebuilding and testing.